【Informatica】CIHで発生するエラーケースや細かな仕様について色々調べたので、ここにそれを記す
2024.12.06はじめに
データ事業本部の川中子（かわなご）です。
記事の導入で何か面白いこと書けないかなぁと5年くらい考えていたのですが、
一切何も思い付かなかったので素直に本題に入っていこうと思います。
直近でも何本か記事を執筆しているCIHは、データハブ連携機能を提供するサービスです。
様々な機能をクラウド側で賄ってくれる、非常に便利で、非エンジニアにも優しいサービス ですが、
反面、細かな仕様についてはドキュメントを確認してもピンと来ない ような場面もあります。
今回はそんな 「この場合はどうなりますの？」 という気品ある疑問にも対応できるように、
いくつか検証を行って分かったCIHの仕様があったので、Tipsを共有する形で記事に残します。
気になる項目について、閲覧頂けたら幸いです。
Tips お品書き
-
- パブリケーションに設定するマッピングタスクの仕様
- 1-1. CIHで使用するマッピングタスクでUpsertを指定
-
- CIHで発生するエラーケース
- 2-1. トピックテーブルで定義されていない列が含まれるデータを連携
- 2-2. トピックテーブルで定義された桁数を超えた値を含むデータを連携
- 2-3. トピックテーブルで定義した型に適さない値を含むデータを連携
- 2-4. トピックテーブルで必須設定された列にNULLを含むデータを連携
- 2-5. トピックテーブルで必須設定された列に重複を含むデータを連携
-
- データ保持期間の仕様
- 3-1. プライベートリポジトリにおける自動データ削除機能の適用
- 3-2. プライベートリポジトリとして使用するDBの稼働状況の影響
- 3-3. データ保持期間外のデータ削除のタイミング
1. パブリケーションに設定するマッピングタスクの仕様
1つ目はパブリケーションに設定するCDIのマッピングタスクに関する仕様です。
検証する中で1つだけ分かった仕様があったので記載します。
1-1. CIHで使用するマッピングタスクでUpsertを指定
パブリケーションに紐づくマッピング/マッピングタスクにおいて、
操作方法でUpsertした場合にパブリケーションを実行できるかどうかを検証しました。
-
マッピングのターゲットにおいて
Upsertを選択(更新キーは選択できません)
-
マッピングタスクにおいても
Upsertが選択されている状態
-
パブリケーションを実行すると、イベントでは以下のようなログでエラーになる
エラーになったイベントログをマウスでホバーすると以下のような文章が表示されます。
Publishing to topic failed. [FATAL] Fatal runtime error occured : [Upsert operation is not allowed for Cloud Integration Hub]
CIHはあくまでもデータ連携のハブ機能を提供するサービスなので、
データベースをデータを更新する Updateなどの連携方法は想定されていない ようです。
2. CIHで発生するエラーケース
次にトピックテーブルの設定や、連携するデータを色々変えてみて、
CIHで発生するエラーケースについて検証から分かった内容を記載していきます。
2-1. トピックテーブルで定義されていない列が含まれるデータを連携
2-1, 2-2の項目では以下の設定のトピックテーブルを使用します。
カラムの必須設定はどのカラムでも有効にはしていません。
定義したテーブルにはIndexというカラムがありますが、
このIndexというカラムを持たないデータをパブリッシュしたときの挙動を確認します。
-
Indexカラムの名前をIndex_numberに変更
-
Index列は全てNULLでデータが格納された
テーブルで 定義された列がパブリッシュされない場合は、全てNULLとして格納 されます。
この検証を実施したとき、イベント画面では特にエラーにはなりませんでした。
またCDIのモニタで確認しても、警告もなく成功ステータスで表示されるので、注意が必要です。
2-2. トピックテーブルで定義された桁数を超えた値を含むデータを連携
次は32桁に設定したトピックテーブルに対して、32より大きい桁数を持つデータを連携してみます。
-
33桁の値を持つデータをパブリッシュ
-
文字の末尾がトリムされた状態で格納された
設定した桁数を超えたデータは、先頭から設定桁数分の文字列を取り出した形で格納 されます。
こちらもCIHのイベント画面やCDIのモニタでは特にエラーになりません。
2-3. トピックテーブルで定義した型に適さない値を含むデータを連携
次はIndex列をINT32に設定して、そこに数字ではなく文字列をパブリッシュしてみます。
-
この時点でテーブルの定義が変更されている
-
Index列にtestや-などの文字列を含むデータをパブリッシュする
-
文字列だったデータは全て
0に変換されて格納された
こちらもCIHのイベント画面やCDIのモニタではエラーになりませんでした。
これはリポジトリに使用しているMySQLの仕様なのかなぁと思い、
直接MySQLにInsert文を書いてtestという文字列を格納してみると、エラー文が出力されました。
SQLエラー [1366] [HY000]: Incorrect integer value: 'test' for column 'F_Index' at row 1
型が異なるデータが格納された際、自動で値が変換されてしまうのはInformatica側の仕様 みたいです。
2-4. トピックテーブルで必須設定された列にNULLを含むデータを連携
次からはトピックテーブルのUser_Id列に必須のチェックを入れて検証します。
-
テーブル定義を確認しても、
User_Id列にNOT NULL制約は設定されていない
-
User_id列にNULLを含むデータをパブリッシュする
-
CIHのイベント画面でパブリッシュが失敗ステータスになる
失敗したイベントをマウスでホバーすると以下のエラー文が表示されます。
Publishing to topic failed. Failed to insert rows because the column "User_Id" in "tpc_incremental_load/tbl_recovery" is defined as required but no value is published.
データベースのテーブルに NOT NULL制約は設定されません が、
CIHの方でNULLが含まれているかどうかの確認 をしてくれているみたいです。
エラーが発報された場合はパブリケーションが実行されないため、テーブルには1行も格納されません。
2-5. トピックテーブルで必須設定された列に重複を含むデータを連携
2-4の検証で使用した、User_Id列が必須設定のテーブルに重複データをパブリッシュしてみます。
-
先に10行文のデータを格納しておく
-
完全重複するデータを1行分だけパブリッシュする
-
データはそのまま格納された
今回も特にエラーにはなりませんでした。
必須設定はあくまでもCIH上でNULLの有無を確認 してくれる機能ということですね。
公式のドキュメントでも必須項目の設定は以下のように説明されています。
Required：
You can specify a field in a relational topic table as Required. If you enable this option, ensure that the data is published to the required fields. If the published data doesn't meet the required mandatory fields criteria, the event fails.
Default is disabled.
3. データ保持期間の仕様
最後はトピックに設定できるデータ保持期間の仕様についてです。
3-1. プライベートリポジトリにおける自動データ削除機能の適用
検証環境ではずっとホステッドリポジトリを使用していたので、
自動データ削除の機能がプライベートリポジトリでも適用されるのかを検証しました。
-
毎朝、日本時間の午前8時頃にデータ削除のイベントログが出力されている
-
リポジトリ内の古いデータは全て削除されていた
自動データ削除の機能は プライベートリポジトリでも問題なく稼働 します。
ホステッドリポジトリではデータベースに残っているデータを目視確認はできませんが、
プライベートリポジトリならデータベースに残っているデータを直接確認できるのはメリットですね。
3-2. プライベートリポジトリとして使用するDBの稼働状況の影響
SecureAgentサーバーやプライベートリポジトリで、EC2やRDSを使うケースも多いと思います。
コスト管理などのために日時の停止や起動をスケジュールしている場合、
この停止状態がデータの自動削除機能に影響があるのかどうかを検証しました。
- 朝8時にデータ削除失敗のエラーイベントが出力されている
イベントにマウスでホバーすると以下のエラー文が出力されます。
Error in publication repository cleanup.
どうやらCIHのシステム上では、日本時間の08:00にデータ削除が実行 されるようで、
その時間にサーバーやデータベースが稼働していれば正常にデータ削除が実行されました。
3-3. データ保持期間外のデータ削除のタイミング
最後に、トピックに設定できるデータ保持期間設定の影響についてです。
-
データ削除のイベントログから
メンテナンスレポートを出力する
-
データ削除の対象やステータス、対象日時が一覧表示される
メンテナンスレポートにはDeleted Publications That Ran Prior To Date列があり、
この列の日時以前にパブリッシュされたデータが削除の対象になっています。
上記キャプチャは12/04 08:00(JST)に実行されたイベントログから取得したもので、
データ保持期間を1日に設定したトピックは12/02 00:00(UTC)以前のデータが対象でした。
日本時間に直すと12/02 09:00(JST)になります。
例として12/02 09:01(JST)にパブリッシュしたデータを考えると、
そのデータが削除される最短のタイミングは、12/05 08:00(JST)となります。
データ保持期間を1日に設定していても、実際は1日以上保持される ということですね。
まとめ
以上、直近の検証で分かったCIHの仕様詳細について、Tips形式でまとめてみました。
特にエラーについては想定とは異なる結果になる検証がいくつかあり、
CIHの便利さの反面、意識して連携ジョブを設計する必要性が見えてきました。
桁数のトリムや型の自動変換などの各種エラーを検知するためには、
マッピングの方でエラーを検知するトランスフォーメーションを実装する必要 があります。
これはAPIで連携する場合でも同様です。
とはいえやはり、各種ジョブの連携を疎結合にできるハブ機能は強力 なので、
今回紹介したような細かい仕様をしっかりと理解して、上手にCIHを使いたいですね。
最後まで記事を閲覧頂き、ありがとうございました。
少しでもこの記事が開発の参考になれば幸いです。
